\section{CyberOrg-MMOG API}
\label{ch:evaluation}

Our research goal is to provide a generalized framework for various genres of MMOGs that can trade resources and game contents in an open market. This allows a game server to buy resources whenever needed from this market that we expect will offer us a significant scale-up. Various services like searching for available resources and game contents can be provided by the broker in forms of web services. These web services could be integrated into the game client or can be provided by a separate third party application agent. In our experiment, we used web services for accessing these services. 

\begin{figure}
\centering
\label{fig:arch}
\includegraphics[scale=0.3]{arch}
\caption{Architecture.}
\end{figure}

\subsection{Design and Implementation}
In our prototype implementation, we have used Actor Architecture \cite{actor} developed and maintained by open systems laboratory, university of Illinois at Urbana-Champaign. Actor Architecture (AA) is a middleware which provides an execution environment for actors. An instance of the AA run-time system is known as a platform, which chains actors implementing on one physical machine. AA has several layers of mechanism that manage different services: Actor Management Service keeps and manages state information for all actors in the platform including both running and mobile actors; Message Delivery Service are responsible for handling all messages in the current AA platform; Message Transport Service provides messages between AA platforms; Advance Service provides match-making and brokering services. Actor Architecture provides environment to running actors concurrently and exist across distributed system. Specifically, the Java VM is left with the task of scheduling actor threads. Our implementation of CyberOrgs for MMOG is an extension of the core CyberOrg API \cite{cyber} that adds two key components to an AA platform: \emph{Directory  Manager} for CyberOrgs and Games(CDM and GDM respectively) and \emph{Broker}. Also other interfaces for Game Clients, Game Providers and Resource Provider implemented  as illustrated in Figure 5. We plan to use Quake 2 \cite{idsoft} for the evaluation. In our experiment, each game client is considered as an actor where each game world/zone or MOD of the game can be considered as a CyberOrg. Each CyberOrg may contain one or more actors performing as a server. 


Following subsections are organized as follows: Subsection 6.2 describes the flow of information throughout our proposed system and section 6.3 explains some of the interfaces used in our API to better understand the functionality of the system.
\subsection{Basic Workflow}
Our proposed system is shown on Figure 5. The task of a broker is to provide different services to game players, resource owners and game owners by providing separate interfaces to them. These services include searching for new games, new resources (for game owners), payment mechanisms, providing default policies and customization options and storing policies to a repository etc. A directory manager provides yellow pages services to search for existing resources and might help the user to find out appropriate resources to accomplish his goals.

After connected to a broker a game developer may want to register his game and define new/customize existing policies. A resource owner may register his resources to the broker and also defines his own policies. If a contract is signed between these two parties a resource owner allows the game owner to use his resources and a game server thus created and registered at the directory manager through the broker. Similarly a game player can find a suitable server using his own policies or by using policies already offered by a game developer. After finding out a server all interactions are done between a server and a client during the game session. 

Figure 6(a) and 6(b) shows the flow of information among different parties. One crucial part of these communications is maintaining the same game state for several servers. This is the case that is common when the game world becomes large and population increases to a point where a single server can not serve the purpose. We still working on maintaining the consistent state among servers. One possibility is to adopt a combination of zoning, instancing and replication \cite{rp-6, npsnet, Mauve} and by exploiting the advantage of limited visibility (Area-Of-Interest). Following subsection briefly explains program fragments that are being used to facilitate communication among different parties.

\begin{figure}
  %\centering
  \subfloat[Flow diagram of a game session]{\label{fig:nonmmo}\includegraphics[width=0.5\textwidth]{../flow1.jpg}}  
  \hspace{3mm}        
  \subfloat[Flow diagram for buy/sell of resources.]{\label{fig:mmo}\includegraphics[width=0.5\textwidth]{../flow2.jpg}}
  \caption{Flow diagrams}
  \label{fig:MMO}
\end{figure}

\subsection{State Consistency}
Developing MMOGs often poses challenges to system designers and developers. One of the biggest challenges is to maintain the consistency as well as keeping the system scalable. In a highly interactive game or simulation the number of interactions increases with the increase of population. The data rate often becomes so high it makes the server perform poorly. This is a very common event in most online games at pick time and causes the game lag. That means game clients receiving responses from the server at a rate much slower than required rate for a smooth gaming experience. Following subsections discusses some approaches that are developed and being used by some MMOGs as well as how we can take advantage of these approaches.

\subsubsection{Interest Management and Seamless Migration to another Zone}
Scalability is a very critical issue when developing MMOGs or multi-user simulation environments. In most modern MMOGs, scalability is achieved through interest management; in other words by dividing the virtual world into smaller areas or zones where each zone is managed by one server \cite{Dewan}. However, due to unpredictable nature of hotspot creation in a zone this approach, alone does not always offer the performance and scalability we seek. Besides, in a static distribution of these areas makes it hard when client tries to migrate from one region to another. In some games this is done using portals. Portals are gateways used to transport a player from one region to another and manages the lag by presenting the user a loading screen or special effect that does not necessarily involves a server. But this is not often the case for most games and many developers might want to avoid this kind of solution. This approach provides a discrete view to the users as they can not see objects beyond the zonal  boundaries. Some MMOGs might need a vast open world without these gateways and require to migrate a gamer from one zone to another seamlessly. In \cite{Lu}, Lu et al. pointed out a model to communicate player interactions based on the player behaviour and defined the concept of an aura, an area enclosed by a sphere for interest management. This behavioural modelling is dynamic in nature and is based on the altitude and viewer range of view. In a nutshell, this model only enables the server deal with the entities that are in the view radius of the player. Knutsson et al.'s P2P Support for Massively Multiplayer Games \cite{Knutsson} and Iimura et al.'s Zoned Federation of Games Servers \cite{Iimura} proposed a discrete view of the zones; all computation in a zone is handled by a server and has a discrete view of the world. This idea simplifies the design and helps to develop a more scalable and robust game. 


\begin{figure}
  %\centering
  \subfloat[Zones with hexagonal shape]{\label{fig:hexzone}\includegraphics[width=0.4\textwidth]{hexzone.jpg}}  
  \hspace{3mm}        
  \subfloat[Migration of an entity from A to B]{\label{fig:zonemig}\includegraphics[width=0.4\textwidth]{zonemigration.jpg}}
  \caption{Seamless migration between zones}
  \label{fig:zone}
\end{figure}

In our implementation, we employed some of these ideas. We propose to have each zone as a hexagon heavily used in cellular networks. There are other shapes that could be used are circular, elliptical, square etc. However, hexagonal shapes provide more advantages than other shapes. The reason behind this is hexagonal shape is very close to circular shape and covers a large area. Each zone is handled by a CyberOrg hosted by a single or multiple game servers. As we can see from figure 7 each edge of the hexagon is shared with another zone. For a smooth transition from one zone to another the area near the boundaries are replicated \cite{rtf} on both servers and mostly created with static, non-movable objects. The bottom part of the figure explains how this movement is handled in a seamless manner. 

\emph{Step 1:} The entity moves within zone A represented as CyberOrg A into the overlap and is replicated as a shadow entity on the CyberOrg representing zone B. It is important to start the handoff process as soon as the entity's area of interest falls into the overlapped region. A separate communication channel is established between CyberOrg A and B as soon as the handoff process starts.\\
\\
\emph{Step 2:} After the entity passes the half way of the overlap,  CyberOrg A automatically changes its status in A from active to shadow and vice versa for CyberOrg B.\\
\\
\emph{Step 3:} As soon as the entity leaves the overlap and completely in zone B, CyberOrg A removes it from zone A.\\
\\
If the entity is a player's avatar, it is important to transfer the connection between him and CyberOrg A to CyberOrg B during step 2. In our implementation, the width of the overlapping zone is equal to the diameter of the area of interest (the view range surrounding the player in 2D case) of the player.



\subsection{Crowding and Load Balancing}
Crowding happens when many players move to the same zone. As each zone has limited resources it makes the game server perform poorly if the population gets too high for the server to handle. Crowding violates the quality of service and affects gaming performance. The simple distribution model of resources among zones might not work when crowding happens. Therefore, only even distribution of resources among zones might not be the best approach for balancing the load. In most cases, this distribution is very random in nature and can not be predicted in advance. 

To understand crowding properly, we need to understand the reasons that cause it. In \cite{Chen} Chen et al. pointed out that when many players move into the same zone, causes ``flocking'', a MMOG pattern that can not be ignored. The reason behind this could be the zone is more interesting for its rich content. In some games like real time strategy games and war games could be scheduled for special battles at a specific time. Also people are more likely to play at their leisure time. Therefore, games could be less overloaded during work hours and more overloaded during weekends and times when people do not work. Obviously, this also depends on the timezones and the number of players from those timezones as well.

\begin{figure}
\centering
\includegraphics[scale=0.35]{crowding}
\caption{Load balancing.}
\end{figure}


As we know from the background study of CyberOrgs \cite{cyber} that CyberOrgs separate the concern of computation and resources through resource encapsulation. This unique property of CyberOrg can be exploited to take advantage on the crowding issue. In MMOG-CyberOrgs model all parties buy and sell resources through an open market. Separate backup servers could be used (through negotiation and contract) when the load is high. Obviously, in this model separating the concern of resources from computation will create state inconsistencies. We employ a shared memory model only for this purpose. To specify more clearly, all databases that are related to the same game zone will be shared among the CyberOrgs that serve that specific overloaded zone. In figure 8, CyberOrg B can be used to provide resources if Zone A is overloaded and the resource that CyberOrg B is hosting can be made available through a pay-per-use contract between them.



